Managed Service Provider (MSP) Support — Feature Guide

1. Overview

Managed Service Provider (MSP) support allows a single platform tenant to serve multiple client organizations — referred to as Customers — from one unified instance, while keeping each Customer's users, tickets, teams, and configuration properly separated.

Instead of provisioning a completely separate platform instance for every client, an MSP-enabled tenant can:

• Onboard multiple Customers under one tenant
• Automatically identify which Customer a user or ticket belongs to, based on email domain
• Keep each Customer's users, tickets, groups, service teams, attributes, and audit history isolated from other Customers
• Apply Customer-specific configuration such as SLA targets, Service Portal branding, and enabled ticket routing queues
• Give tenant administrators centralized oversight across all Customers, while giving each Customer's own users visibility limited to their own organization

This is intended for organizations that deliver IT or business services to multiple external client companies from a shared platform tenant — for example, an MSP supporting several client accounts, each with its own users, domains, and service expectations.

2. Key Concepts

Concept	Description
MSP Tenant	A platform tenant with MSP mode enabled, capable of hosting multiple Customers.
Customer	A distinct client organization configured within an MSP tenant. Functions as its own workspace with its own users, groups, attributes, audiences, audit logs, service teams, and enabled modules.
Customer Domain	One or more email domains associated with a Customer (e.g., abccorp.com, abccorp.in) used to automatically identify which Customer a user belongs to.
Default Customer	A Customer designated to automatically receive users whose email domain is a recognized public/consumer domain (e.g., gmail.com) that isn't mapped to any specific Customer. Any Customer can be designated as the Default Customer, and this can be changed at any time.
Customer User	A Customer-level role. Can access the Service Portal and view only their own tickets.
Customer Executive	A Customer-level role. Can access the Service Portal and view all tickets raised within their own Customer.
Ticket User	A general-purpose role (not tied to a specific Customer) that allows a person to submit tickets. Can be held alongside a Customer-level role.
Bot User	A general-purpose role (not tied to a specific Customer) used for automated/bot accounts that submit tickets on a user's behalf (e.g., via chat/collaboration channels).
MSP Administrator (Tenant Admin)	A tenant-level administrator with visibility and management access across all Customers.
Service Team	A Customer-specific team (e.g., IT, HR) used to organize ticket routing.
Queue	A routing category within a Service Team (e.g., "Hardware" and "Software" under an IT team). Queues can be turned on or off per Customer; only the queues enabled for a Customer appear on the Agent UI for that Customer's tickets.
Customer Group	A group defined within a Customer, made up of an Owner and Members. Only Customer-level roles (Customer User, Customer Executive) can be added to a Customer Group.
Customer Attribute	A custom field defined for a specific Customer (e.g., "Entitlement" = Premium/Standard). Can be used in form fields and conditions, in Customer-specific audiences, and on user records within that Customer.
Tenant Attribute	A custom field defined at the tenant level, usable in tenant-level audiences that can reference a specific Customer and one of that Customer's attribute values.
Audience	A rule-based segment — Customer-specific or tenant-level — used to control the visibility of Service Catalog fields or offers on the Agent UI.
Service Portal	The self-service portal used by Customer-facing roles. Look and feel can be configured independently per Customer.

3. MSP Architecture / Hierarchy

MSP Tenant
 └─ Customers (e.g., ABC Corporation, XYZ Corporation, Default Customer)
     ├─ Customer Domain(s) (e.g., abccorp.com, abccorp.in)
     ├─ Users (Customer User, Customer Executive)
     ├─ Groups (Owner + Members, Customer-level roles only)
     ├─ Service Teams
     │    └─ Queues (enabled/disabled per Customer)
     ├─ Customer Attributes & Audiences
     ├─ Service Portal Configuration
     └─ Tickets (associated with this Customer)

A user or ticket is always associated with, at most, one Customer at a time. Tenant-level users and administrators sit above the Customer layer and are not tied to any single Customer.

4. Customer Management

Onboarding a Customer

When creating a Customer, the following is required:

• Name
• Email Domain(s) — one or more domains that identify users belonging to this Customer
• Industry

Optional at onboarding, and editable later:

• Primary Contact — when a Primary Contact is set, they are automatically granted both the Customer User and Customer Executive roles.
• Customer Attributes — custom fields such as "Entitlement" (e.g., Premium or Standard), which can also be used later for SLA and audience configuration.

Any Customer can be designated as the Default Customer and this designation can be changed at any time.

Multiple Domains per Customer

A Customer can have more than one associated domain. For example, if both abccorp.com and abccorp.in are mapped to ABC Corporation, users and tickets from either domain will show the Customer as "ABC Corporation."

Customer as a Workspace

Each Customer functions as its own workspace, with its own Users, Groups, Attributes, Audiences, Audit Logs, Service Teams (with Queues), and enabled platform modules.

MSP-Level vs. Customer-Level Configuration

Configured at MSP (Tenant) Level	Configured at Customer Level
Enabling MSP mode	Customer's email domain(s)
Module Redirection setup (see Section 16)	Customer Attributes & Audiences
Creating and managing the list of Customers	Groups (Owner/Members)
Designating the Default Customer	Service Teams and their Queues (enable/disable)
Tenant-level Attributes & Audiences	Module enablement for that Customer (e.g., turning Ticketing on)
Tenant Admin role and access	Service Portal look-and-feel configuration
	SLA rules based on that Customer's attributes

Enabling Modules for a Customer

For a Customer's users to use a given module (for example, Ticketing), that module must be explicitly turned on for that Customer. Until it is enabled, Customer-level roles cannot access that module even though the Customer exists.

5. Domain Mapping

Domain mapping determines which Customer (if any) a user is automatically associated with, based on their email domain.

User's Email Domain	Result
Matches a domain explicitly mapped to a specific Customer (e.g., abccorp.com → ABC Corporation)	User is automatically associated with that Customer
A recognized public/consumer email domain (e.g., gmail.com, yahoo.com) that is not mapped to any specific Customer	User is automatically associated with the Default Customer
The tenant's own organizational domain(s), including any domain that already existed at the tenant level before MSP was enabled	User remains at the tenant level, with no Customer association

Moving a User Between Customers

A ticket (and its requester) can be moved from the Default Customer to a specific Customer using the bulk operation on the ticket list. For example, moving a ticket raised by jenny@example.com from Default Customer to ABC Corporation will:

• Move Jenny from the Default Customer's user list to ABC Corporation's user list
• Keep Jenny's email domain unchanged — the domain does not need to be, and is not, added to ABC Corporation's mapped domains
• Apply "ABC Corporation" as the Customer value on all of Jenny's future tickets

This reassignment applies only to that individual user. It does not change how future users from the same domain are handled — new users from that domain will continue to follow the standard domain-mapping rules above unless they are also moved individually.

6. User Management

Users can be added under the Users tab either manually or by CSV import.

Scenario	Result
Added at tenant level; domain is mapped to a specific Customer	Automatically added under that Customer's user list
Added at tenant level; domain is a recognized public/consumer domain not mapped to a Customer	Automatically added under the Default Customer's user list
Added at tenant level; domain is the tenant's own organizational domain	Added at the tenant level; no Customer association
Added directly under a Customer	Only Customer-level roles (Customer User, Customer Executive) can be assigned
Added at tenant level	Any role except the Customer-level roles can be assigned

Additional notes:

• The Service Portal Access checkbox, available during both manual onboarding and CSV import, can be used to suppress the welcome email for that user.
• A user can be moved from one Customer (including the Default Customer) to another at any time using the Reassign Customer option.

7. Ticket Management in MSP

• Every ticket is associated with a Customer, based on the requester's identified Customer at the time of creation.
• The ticket list view includes a Customer column.
• The ticket detail page displays the ticket's Customer value.
• On the Agent UI, a Customer dropdown is available; it can be used both to filter the ticket list by Customer and to select a Customer when creating a ticket manually.
• Notes and Watchers on a ticket can include all Customer Users and Customer Executives belonging to that ticket's Customer, plus all tenant-level users.
• Tickets are routed through the Service Teams and Queues enabled for their associated Customer; only the queues enabled for that Customer are available on the Agent UI.
• Using the bulk operation, tickets (and their requester) can be moved from the Default Customer to a specific Customer (see Section 5).

Supported Channels

Ticket creation with automatic Customer identification is supported through:

• Service Portal
• Email
• Microsoft Teams
• Slack

Users who create tickets through Email, Teams, or Slack and are not already associated with a Customer are handled per the domain-mapping rules in Section 5. Users automatically created under the Default Customer through these channels are granted the Ticket User, Bot User, and Customer User roles.

8. Customer Isolation

Each Customer's data is kept separate from other Customers in the following areas:

• Users — each Customer has its own user list.
• Groups — groups are defined within a specific Customer and can only include Customer-level roles.
• Service Teams and Queues — only the queues enabled for a given Customer are available on the Agent UI for that Customer's tickets.
• Attributes and Audiences — Customer Attributes and Customer-specific Audiences apply only within that Customer.
• Audit Logs — each Customer maintains its own audit history.
• Service Portal — look and feel can be configured independently per Customer.
• Tickets and Reporting — ticket visibility is scoped by role (see Section 9) so that Customer Users and Customer Executives only see tickets belonging to their own Customer.

9. Roles and Permissions

Role	Scope	Ticket Visibility (Agent UI & Reports)	Notes
MSP Administrator (Tenant Admin)	Tenant-wide	All tickets, across all Customers	Full visibility and management across all Customers
Customer Executive	Customer-level	All tickets belonging to their own Customer	Can be a Customer Group owner or member
Customer User	Customer-level	Only their own tickets	Can be a Customer Group owner or member
Ticket User	General (not Customer-specific)	Can submit tickets	Can be combined with a Customer-level role
Bot User	General (not Customer-specific)	Can submit tickets (typically automated/bot accounts)	Can be combined with a Customer-level role

Customer-level roles are currently limited to Customer User and Customer Executive. Additional Customer-level roles may be introduced in future releases.

10. Customer-Specific Configuration

The following can vary by Customer:

• Email domain(s)
• Customer Attributes (e.g., Entitlement: Premium/Standard)
• Customer-specific Audiences
• Groups (Owner/Members)
• Service Teams and which Queues are enabled
• Module enablement (e.g., Ticketing on/off for that Customer)
• Service Portal look and feel
• SLA targets, where configured based on Customer Attributes

See Section 4 for the full breakdown of MSP-level vs. Customer-level configuration.

Attributes and Audiences

Customer-specific attributes and audiences: A Customer Attribute (e.g., "Plan Duration") can be created for a specific Customer, then used to build a Customer-specific Audience (e.g., an audience defined by Plan Duration = Yearly). This audience can then be used on the Service Catalog side to show or hide fields or offers on the Agent UI.

Tenant-level attributes and audiences: A Tenant Attribute can be created at the tenant level and used in a tenant-level Audience that targets a specific Customer and one of that Customer's attribute values (for example, an audience for "ABC Corporation" customers with Entitlement = Standard). This audience can likewise be used to show or hide Service Catalog fields or offers on the Agent UI.

11. SLA and Entitlement

SLA templates can define goals that vary based on a Customer's attribute values. For example, using the "Entitlement" Customer Attribute:

Entitlement	First Response Time (FRT) Goal
Premium	1 hour
Standard	3 hours

This allows a single SLA template to apply different targets to different Customers automatically, based on each Customer's configured attribute value, rather than requiring a separate template per Customer.

12. Service Portal

• After logging in, Customer User, Customer Executive, Ticket User, and Bot User roles are routed to the Service Portal.
• Access to the Agent UI or dashboards from the Service Portal is provided through app switches on the Service Portal page. Visibility of these apps is controlled by the Service Portal configuration, in line with each module's subscription/activation status.
• Service Portal Configuration: Look and feel can be configured per Customer from the Service Portal Configuration page. You can create more than one configuration for a given Customer, but only one can be active at a time. If none is active, the default Service Portal configuration takes priority.
• Service Portal Configuration List: All Customer Service Portal configurations are listed here, and each can be turned on or off.

13. Reporting and Data

Ticket visibility in reports and dashboards follows the same scoping as the Agent UI:

Role	Reports & Dashboards
Customer User	Own tickets only
Customer Executive	All tickets for their own Customer
Tenant Admin	All tickets, across all Customers

14. Common Use Cases

Use Case 1 — Known Customer Domain

A user with an email address on a domain mapped to ABC Corporation (e.g., user@abccorp.com) submits a ticket. The ticket is automatically associated with ABC Corporation, and the user appears under ABC Corporation's user list.

Use Case 2 — Unmapped Public Domain

A user emails in from a recognized public/consumer domain that isn't mapped to any Customer (e.g., user@gmail.com). The user and their ticket are automatically associated with the Default Customer, with the Ticket User, Bot User, and Customer User roles applied.

Use Case 3 — Reassigning a Default Customer User

A support team member identifies that a Default Customer ticket actually belongs to XYZ Corporation. Using the bulk operation, they move the ticket (and its requester) to XYZ Corporation. The requester's email domain does not change and is not added to XYZ Corporation's domain list — going forward, that individual's tickets carry XYZ Corporation as the Customer, while any other users on the same domain continue to follow standard domain-mapping rules.

Use Case 4 — MSP Administrator Oversight

A tenant-level MSP Administrator can view and manage tickets, users, and configuration across all Customers, without being limited to a single Customer's data.

Use Case 5 — Customer Executive Review

A Customer Executive at ABC Corporation logs into the Service Portal and reviews all tickets raised by anyone in their organization — not just their own — through the Agent UI and reports.

15. End-to-End Example

1. User: priya@abccorp.com sends an email to request support.
2. Domain Identification: The platform recognizes abccorp.com as a domain mapped to a specific Customer.
3. Customer Identification: The user is identified as belonging to ABC Corporation.
4. Ticket Creation: A ticket is created from the email, with Priya as the requester.
5. Customer Association: The ticket's Customer field is set to "ABC Corporation," visible on the ticket list and detail page.
6. Assignment: The ticket is routed to one of the Service Teams and Queues enabled for ABC Corporation.
7. SLA: ABC Corporation's Entitlement attribute is set to Premium, so the ticket's First Response Time goal is 1 hour.

16. Configuration / Setup Requirements

Prerequisites (one-time setup)

1. Under Tenant Settings, go to Module Redirection Collections and map Module: GES with Module Version: GES, then select Add. This activates the Global Entity Services (GES) user management framework that MSP mode relies on.
2. Turn on the MSP toggle in Tenant Settings.
3. Create your Customers (Name, Email Domain(s), Industry; Primary Contact optional).
4. Designate one Customer as the Default Customer.
5. For each Customer, turn on the modules they need (e.g., Ticketing) under GES module settings.
6. Set up Service Teams and their Queues for each Customer, and enable the queues that should be available.
7. Optionally, configure Customer Attributes, Audiences, SLA rules, and Service Portal look-and-feel per Customer.

Day-to-Day Usage (ongoing)

• Onboarding new users (manually, via CSV, or automatically through email/Teams/Slack/Service Portal)
• Reassigning users and tickets between Customers as needed
• Managing Customer Groups, Attributes, and Audiences
• Monitoring tickets and reports by Customer or across the tenant, depending on role

17. Important Behavior / Rules

Scenario	Expected Behavior
User's domain is mapped to a specific Customer	User and their tickets are associated with that Customer
User's domain is a recognized public/consumer domain, not mapped to any Customer	User and their tickets are associated with the Default Customer
User's domain is the tenant's own organizational domain	User remains at tenant level; no Customer association
A Default Customer ticket/user is moved to a specific Customer	Only that user is reassigned; their domain is unchanged and not added to the new Customer's domain list; future domain-based mappings are unaffected
User added directly under a Customer	Can only be assigned Customer-level roles (Customer User, Customer Executive)
User added at tenant level	Can be assigned any role except the Customer-level roles
A Customer's module (e.g., Ticketing) is not turned on	That Customer's users cannot use that module
A Queue is disabled for a Customer	That Queue does not appear on the Agent UI for that Customer's tickets
More than one Service Portal configuration exists for a Customer	Only one can be active at a time; if none is active, the default configuration applies
Primary Contact is set for a Customer	Automatically granted Customer User and Customer Executive roles

18. Limitations / Considerations

• Only one Service Portal configuration can be active per Customer at a time.
• Customer-level roles are currently limited to Customer User and Customer Executive.
• Automatic Customer identification for ticket creation currently covers the Service Portal, Email, Microsoft Teams, and Slack channels.
• Reassigning a user from the Default Customer to a specific Customer is an individual action and does not retroactively or automatically map their domain to that Customer.

19. FAQ

What is MSP support?

MSP support allows a single tenant to host multiple Customers, each with isolated users, tickets, teams, and configuration, while giving tenant administrators centralized management across all of them.

Can one MSP tenant manage multiple Customers?

Yes. Any number of Customers can be onboarded under an MSP-enabled tenant.

How is a user associated with a Customer?

Primarily through their email domain. A domain mapped to a specific Customer associates the user with that Customer; a recognized public/consumer domain not mapped to any Customer associates the user with the Default Customer; the tenant's own organizational domain keeps the user at the tenant level.

What happens if a user's domain isn't mapped to any Customer?

If it's a recognized public/consumer domain, the user is placed under the Default Customer and can be reassigned later. If it's the tenant's own organizational domain, the user stays at the tenant level with no Customer association.

Can different Customers have different SLA targets?

Yes. SLA goals can be configured based on a Customer's attributes — for example, a Premium entitlement can carry a faster First Response Time goal than a Standard entitlement.

Can a Customer Executive see tickets from other Customers?

No. A Customer Executive can see all tickets within their own Customer only, not other Customers.

Can an MSP Administrator manage multiple Customers?

Yes. The MSP Administrator (Tenant Admin) has visibility and management access across all Customers in the tenant.

How is Customer data kept separate?

Each Customer has its own users, groups, service teams and queues, attributes, audiences, and audit logs. Ticket and report visibility is also scoped by role, so Customer Users and Customer Executives only see their own Customer's data.

Can a Customer have more than one email domain?

Yes. Multiple domains can be mapped to a single Customer; users from any of those domains are associated with the same Customer.

Which channels support automatic Customer identification for tickets?

Service Portal, Email, Microsoft Teams, and Slack.